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EXECUTIVE  SUMMARY 


This  report  describes  some  results  of  the  project  “More  reliable  wireless  communications  through  po¬ 
lar  codes,”  funded  in  fiscal  year  2015  by  the  Naval  Innovative  Science  and  Engineering  (NISE)  program  at 
SSC  Pacific. 


OBJECTIVE 

The  purpose  of  the  project  is  to  determine  if  polar  codes  can  outperform  the  forward  error  correction 
(FEC)  currently  used  in  Navy  wireless  communication  systems.  The  project  team  has  implemented  an  ad¬ 
vanced  decoding  method  called  cyclic  redundancy  check  (CRC)-aided  list  decoding. 


RESULTS 

Our  simulation  results  show  that  polar  coding  can  produce  results  very  similar  to  the  FEC  used  in  the 
Digital  Video  Broadcasting  -  Satellite  -  Second  Generation  (DVB-S2)  standard,  and  can  provide  up  to  15 
percent  higher  throughput  by  using  code  rates  not  provided  in  the  DVB-S2  standard. 


RECOMMENDATIONS 

In  any  application  for  which  the  DVB-S2  FEC  is  considered,  polar  coding  with  CRC-aided  list  decod¬ 
ing  with  N  =  65536  should  also  be  considered. 


IV 
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1.  INTRODUCTION 


Polar  codes  are  a  new  type  of  forward  error  correction  (FEC)  codes,  introduced  by  Arikan  in  [1],  in 
which  he  proved  that  they  can  achieve  the  capacity  of  any  binary  memoryless  symmetric  channel  with  effi 
cient  encoding  and  decoding. 

In  fiscal  years  (FY)  2014  and  2015,  SSC  Pacific’s  Naval  Innovative  Science  and  Engineering  (NISE) 
program  funded  the  project  “More  Reliable  Wireless  Communications  Through  Polar  Codes”  to  study 
polar  codes  and  determine  if  they  can  outperform  the  forward  error  correction  (FEC)  currently  used  in 
Navy  wireless  communication  systems.  The  project’s  FY  2014  results  are  described  in  [2].  In  FY  2015 
the  project  team  has  implemented  an  advanced  decoding  method  called  cyclic  redundancy  check  (CRC)- 
aided  list  decoding,  and  simulated  its  performance  in  a  wide  variety  of  cases.  This  report  documents  the 
results  of  those  simulations.  The  project’s  other  FY  2015  work  will  be  published  separately. 

Section  2  describes  the  basics  of  polar  coding.  CRC-aided  list  decoding  is  described  in  Section  3.  Sec 
tion  4  describes  the  scope  of  our  study,  and  Section  5  presents  the  results.  Section  6  gives  details  of  how 
we  implemented  the  decoder.  Finally,  Section  7  concludes  the  report. 
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2.  POLAR  CODING 


Several  versions  of  polar  coding  have  been  published.  This  section  is  intended  to  indicate  which  ver¬ 
sion  is  used  in  this  work.  For  background  and  motivation  of  this  material,  see  our  previous  technical  report 
[2]. 

For  any  n  >  0,  we  can  specify  a  polar  code  of  length  N  =  2n  by  choosing  a  subset  A  C  {!>•••>  N}. 
If  A  has  K  elements,  we  get  an  (TV,  K )  block  code.  A  must  be  chosen  well  for  good  error-correction  per¬ 
formance.  We  used  the  method  of  [3]. 


The  polar  encoder  uses  a  row  vector  u  of  length  TV.  Let  u ^  be  the  subvector  containing  elements 
whose  indices  are  in  A,  and  let  u Ac  be  the  subvector  containing  the  remaining  TV  —  K  elements  of  u.  The 
encoder  constructs  u  by  filling  with  K  information  bits,  and  setting  u^c  to  predetermined  values,  usu¬ 
ally  all  0’s.  These  predetermined  values  are  called  frozen  bits.  The  encoder  outputs  x  =  uG^y  where  Gjy 


is  the  TV  by  TV  matrix  F^Un,  where  F 


1  0 
1  1 


F®n  js  tensor  power,  and  TIn  is  a  permutation 


matrix  called  the  bit-reversal  operator ,  defined  in  Section  VII  of  [1].  This  encoder  can  be  implemented 
with  complexity  0(TV  log  TV). 


Arikan  showed  in  [1]  that  polar  codes  can  achieve  capacity  using  a  successive  cancellation  (SC)  de¬ 
coder.  This  decoder  computes  estimates  u\, . . .  ,un,  one  at  a  time,  in  order,  with  complexity  0(TV  log  TV). 


2.1  SYSTEMATIC  POLAR  CODING 

Systematic  polar  coding  was  introduced  in  [4].  The  systematic  polar  encoder  also  computes  x  = 
UF®nIl7v,  but  the  information  bits  are  found  in  x  rather  than  in  u.  Specifically,  [4]  showed  that  for  any 
vector  of  K  information  bits,  there  is  a  unique  u  such  that  is  all  0’s  and  is  the  specified  informa¬ 
tion  bits,  where  w  =  uF®n. 

The  systematic  SC  decoder  computes  the  estimate  u  in  the  same  way  as  the  non-systematic  decoder, 
and  also  computes  w  =  uF(g)n.  Then  is  the  desired  estimate  of  the  information  bits. 

Arikan  proved  in  [4]  that  systematic  polar  coding  has  the  same  frame  error  rate  (FER)1  as  non-systematic 
polar  coding.  Arikan  also  provided  simulation  results  showing  that  systematic  polar  coding  has  a  lower  bit 
error  rate  (BER)  than  non-systematic.  This  result  has  been  replicated,  but  to  our  knowledge  it  has  never 
been  proven. 


1  Also  known  as  block  error  rate. 
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3.  LIST  DECODING 


Recall  from  Section  2  that  the  SC  decoder  estimates  uif . . . ,  un,  one  at  a  time,  in  order.  For  conve¬ 
nience,  we  introduce  some  non-standard  notation.  For  any  k  <  N  and  any  sequence  of  bits  61, 62, . . . ,  6&, 
let  P(&i,  . .  • ,  be  the  decoder’s  estimate  of  the  probability  that  u  begins  with  (61,62?  •  •  • ,  6&). 

P(6i,  62, ... ,  6fc)  depends  on  the  decoder’s  input,  but  to  make  the  notation  simpler  we  do  not  include  the 
decoder’s  input  in  the  expression.2 

The  decoder’s  decisions  can  be  viewed  as  choosing  a  path  down  a  binary  tree  of  height  N,  with  2N 
leaves  representing  all  possible  decodings  of  a  block.  Figure  1  shows  an  example  of  the  first  four  choices. 


0000  0001  0010  0011  0100  0101  0110  0111  1000  1001  1010  1011  1100  1101  1110  1111 


Figure  1 .  SC  decoding  tree. 

This  diagram  shows  that  the  decoder  chose  u\  =  0,  U2  =  1,  U3  =  0,  and  U4  =  1. 

The  SC  decoder  has  a  simple  rule  for  choosing  each  bit.  When  choosing  if  the  ith  bit  is  frozen,  it 
chooses  the  known  value  of  u%.  Otherwise,  it  computes  the  ratio 

P(ui,u2,  ■  ■  .,Ui- 1, 1) 

It  chooses  Ui  =  0  if  this  ratio  is  greater  than  1,  and  ui  =  1  if  this  ratio  is  less  than  1. 

One  major  disadvantage  of  this  method  is  that  the  decoder  cannot  correct  an  error  made  earlier  in  the 
process.  In  [5],  Tal  and  Vardy  introduced  list  decoding ,  also  called  successive  cancellation  list  decoding 

2P(b\ ,  62,  •  •  • ,  6fc)  is  computed  using  an  efficient  recursive  formula,  but  the  true  probability  cannot  be  computed  efficiently. 
The  estimate  differs  from  the  true  probability  because  the  recursive  formula  does  not  take  into  account  the  knowledge  of  frozen 
indices  >  k. 
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(SCL),  to  mitigate  this  problem.  They  found  that  list  decoder’s  error  correction  performance  was  signifi¬ 
cantly  better  than  SC,  at  the  cost  of  higher  computational  complexity. 

The  list  decoder  follows  multiple  paths  down  the  decoding  tree.  Figure  2  shows  an  example  of  a  list 
decoder  estimating  u\  through  14. 


0000  0001  0010  0011  010c  0101  0110  0111  1001  1010  1011  1100  1101  1110  1111 


Figure  2.  List  decoding  tree  with  L  =  4. 

For  convenience,  assume  that  none  of  the  first  four  indices  are  frozen.3  Instead  of  choosing  if  u\  is 
0  or  1,  the  list  decoder  chooses  both,  and  likewise  for  74  •  In  this  way,  it  generates  a  list  of  candidate  de- 
codings.  After  two  steps,  the  list  contains  four  candidates:  (0,  0),  (0,  1),  (1,  0),  and  (1,  1).  After  each  non- 
frozen  bit,  the  number  of  candidates  doubles  until  it  exceeds  a  predetermined  maximum.  This  maximum  is 
called  the  list  size ,  and  is  represented  by  the  symbol  L. 

Figure  2  shows  an  example  with  L  —  4.  In  the  third  step,  the  decoder  computes  probability  estimates 
for  all  eight  possibilities:  P(0, 0, 0),  P( 0, 0, 1),  P( 0, 1, 0),  P(0, 1, 1),  P(  1,  0,  0),  P(l,  0, 1),  P(  1, 1, 0), 
and  P(  1, 1, 1).  It  retains  in  the  list  the  L  candidates  with  the  largest  probability  estimates.  In  the  example, 
these  are  (0,  0, 1),  (0, 1, 0),  (0, 1, 1),  and  (1,  0,  0). 

After  the  list  has  been  pruned,  the  decoder  does  not  compute  probability  estimates  for  all  possibilities, 
but  only  the  2 L  possibilities  that  are  extensions  of  the  candidates  in  the  list.  In  the  example  shown  in  2,  it 
computes  P( 0,  0, 1, 0),  P(0, 0, 1, 1),  P( 0, 1,0, 0),  P(0, 1, 0, 1),  P(0, 1, 1, 0),  P(0, 1, 1, 1),  P(l,  0,  0,  0), 
and  P(l,  0,  0, 1).  Again,  the  L  candidates  with  the  largest  probability  estimates  are  maintained  in  the  list. 
The  computational  complexity  of  the  list  decoder  is  roughly  L  times  that  of  an  SC  decoder. 

After  N  steps,  the  decoder  has  a  list  L  candidates  that  each  include  N  bits,  and  it  has  a  probability  for 
each  one.  It  chooses  u  to  be  the  most  probable  candidate. 

3 In  most  practical  polar  codes,  the  first  four  indices  are  all  frozen. 
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Tal  and  Vardy  experimented  with  list  decoding  a  (2048,  1024)  polar  code  and  found  that  list  decoding 
with  small  to  moderate  list  sizes  could  match  the  FER  of  a  maximum  likelihood  decoder.4  The  lower  the 
Eb/No ,  the  larger  list  size  is  needed:  with  L  =  2  the  list  decoder  matches  the  maximum  likelihood  decoder 
for  Eb/No  >  2.75  decibels  (dB),  and  with  L  =  32  it  matches  for  Eb /No  >  1.75  dB.  However,  even 
with  the  improvement  caused  by  list  decoding,  the  error-correction  performance  of  polar  codes  is  poor 
compared  to  turbo  and  low-density  parity  check  (LDPC)  codes. 


3.1  CRC-AIDED  LIST  DECODING 

Tal  and  Vardy  [5]  found  that  a  slight  change  could  yield  even  better  results,  outperforming  the  LDPC 
code  used  in  the  WiMax  standard.  They  ran  simulations  of  list  decoding  and  found  that  when  the  decoder 
produces  the  wrong  answer,  often  the  correct  answer  is  in  the  list.  Therefore,  instead  of  always  choosing 
the  most  probable  candidate,  it  would  help  to  be  able  to  pick  the  correct  answer  out  of  this  list.  The  use  of 
a  CRC  helps  to  achieve  this  goal. 

A  CRC  is  an  error  detection  code.  It  is  specified  by  a  binary  polynomial  of  degree  d,  where  d  can  be 
any  positive  integer.  The  CRC  takes  as  input  an  information  bit  vector  of  any  length,  and  outputs  a  binary 
vector  of  length  d ,  called  the  check  bits  or  the  parity  bits.  Both  the  information  bits  and  the  check  bits  are 
sent  to  a  receiver.  The  receiver  applies  the  same  CRC  to  the  received  information  bits,  and  checks  if  the 
result  matches  the  received  check  bits.  If  they  do  not  match,  an  error  has  occurred.  For  a  randomly  chosen 
bit  vector,  the  probability  of  passing  the  CRC  is  More  details  about  CRC  can  be  found  in  [7]. 

In  polar  coding  with  CRC-aided  list  decoding,  we  use  an  (2V,  K)  polar  code  and  a  d-bit  CRC.  We  start 
with  K  —  d  information  bits,  and  use  the  CRC  to  compute  d  check  bits.  We  append  the  check  bits  to  the 
information  bits,  and  input  all  K  bits  to  the  polar  encoder.  The  encoder  outputs  N  bits,  which  are  sent  to 
the  receiver.  At  the  receiver,  the  list  decoder  works  as  described  above  until  the  last  step.  Instead  of  simply 
choosing  the  most  probable  candidate,  the  decoder  uses  the  CRC  to  test  the  candidates  for  errors.  If  one 
or  more  candidates  pass,  the  decoder  outputs  the  most  probable  among  those  that  pass.  If  none  of  the  can¬ 
didates  pass,  the  decoder  outputs  the  most  probable  candidate,  and  also  outputs  a  flag  indicating  that  the 
result  is  incorrect. 

The  price  we  pay  for  using  CRC  is  that  we  have  K  —  d  information  bits  instead  of  K.  We  can  compen¬ 
sate  by  increasing  K.  This  means  we  have  fewer  frozen  bits,  so  the  error-correction  capability  of  the  polar 
code  is  decreased,  but  in  return  we  get  additional  error-correction  capability  from  the  CRC.  If  d  is  chosen 
well,  we  receive  a  net  gain. 

For  the  rest  of  this  report  we  will  use  the  symbol  K{  for  the  number  of  information  bits  per  block.  K 
will  always  be  the  number  of  non-frozen  bits  in  a  polar  code. 


4  A  naive  implementation  of  a  maximum  likelihood  decoder  would  have  to  compute  the  probability  of  all  2K  possibilities.  In 
[6]  it  was  shown  that  this  complexity  can  be  reduced  to  roughly  cubic,  but  this  is  still  too  high  to  be  practical  when  N  =  2048.  Tal 
and  Vardy  did  not  implement  a  maximum  likelihood  decoder,  but  they  did  compute  a  lower  bound  of  its  FER  and  found  that  the 
list  decoder  came  very  close  to  this  bound,  close  enough  that  the  difference  is  not  visible  in  a  graph.  The  FER  of  the  maximum 
likelihood  decoder  is  less  that  the  FER  of  the  list  decoder,  but  greater  than  the  lower  bound,  so  all  three  of  these  values  are  very 
close. 
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4.  PARAMETERS  OF  THE  SIMULATIONS 


The  BER  of  CRC-aided  list  decoding  depends  on  several  parameters  involving  the  channel,  the  polar 
code,  the  CRC,  and  the  decoder.  The  following  subsections  describe  these  parameters. 


4.1  THE  CHANNEL 

In  this  report,  the  “channel”  encompasses  everything  between  the  encoder  output  and  the  decoder  in¬ 
put.  All  channels  used  in  this  report  are  binary-input  additive  white  Gaussian  noise  (AWGN)  channels. 

Such  a  channel  is  determined  by  a  parameter  a.  The  channel  input  b  can  be  0  or  1,  and  the  output  is  (— 1)6+ 
n,  where  n  is  a  sample  from  a  normal  distribution  with  mean  0  and  standard  deviation  a.  Each  time  an¬ 
other  bit  is  sent,  a  new  n  is  chosen,  and  all  the  n’s  are  independent. 

An  AWGN  channel  can  also  be  described  by  the  ratio  of  symbol  energy  ( Es )  to  noise  spectral  den¬ 
sity  (No).  We  have  normalized  the  energy  so  that  Es  =  1  and  Nq  =  2a2.  We  also  frequently  use  the 
ratio  Eb  /No  where  E 5  is  the  bit  energy ,  or  more  precisely,  the  energy  per  information  bit.  Thus,  E^/No  = 

( Es/No)/r ,  where  r  is  the  code  rate  Ki/N.  Both  Es/No  and  E^/No  are  usually  expressed  in  decibels. 

Most  FEC  literature  uses  AWGN  channels,  so  we  did  also,  making  it  easier  for  us  to  compare  our  re¬ 
sults  to  previous  results  on  polar  codes  and  other  FEC. 


4.2  THE  POLAR  CODE 

For  any  N  that  is  a  power  of  2  and  any  K  <  TV,  an  (TV,  K )  polar  code  can  be  specified  by  choosing  a 
iT-element  subset  of  {1, . . . ,  TV}.5  This  subset  is  normally  chosen  to  optimize  the  performance  of  the  code 
for  a  particular  channel.  We  constructed  polar  codes  using  the  method  of  Tal  and  Vardy  [3].  All  the  codes 
used  in  this  report  were  optimized  for  AWGN  channels  of  various  Es/No  values.  The  Tal/Vardy  method 
requires  specifying  a  fidelity  parameter  p\  we  used  p  =  512. 

The  Tal/Vardy  method,  like  most  polar  code  construction  methods,  is  designed  to  minimize  the  FER  of 
an  SC  decoder.  In  the  process,  it  computes  an  upper  bound  for  this  FER.  In  our  previous  work,  we  found 
that  if  p  >  256  and  FER  <  10-3,  then  this  upper  bound  is  very  close  to  the  true  FER.  In  contrast,  there 
is  no  method  known  to  predict  the  performance  of  a  list  decoder  except  running  a  large  number  of  trials. 
Thus,  a  code  that  is  optimal  for  SC  decoding  in  a  given  AWGN  channel  may  not  be  optimal  for  list  decod¬ 
ing,  and  a  code  designed  for  a  different  AWGN  channel  might  perform  better. 


4.3  THE  CRC 

The  CRC  polynomial  can  be  any  polynomial  with  coefficients  in  {0, 1}  such  that  the  constant  term  is 
1.  The  number  d  of  check  bits  equals  the  degree  of  the  polynomial.  Although  d  is  determined  by  the  poly¬ 
nomial,  we  treated  them  as  two  separate  parameters:  we  can  compare  CRC  lengths,  or  compare  different 
polynomials  at  the  same  length.  It  is  impossible  to  compare  different  lengths  at  the  same  polynomial. 

5It  is  also  possible  to  change  the  code  by  specifying  the  N  —  K  frozen  bits.  We  follow  the  usual  convention  that  all  frozen  bits 
are  0. 
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4.4  THE  DECODER 


After  specifying  the  above  parameters,  there  are  two  things  left  to  vary,  the  list  size  and  the  decoder’s 
knowledge  of  the  channel.  When  the  decoder  receives  a  channel  output  y,  it  must  compute  the  likelihoods: 
if  a  0  is  transmitted,  what  is  the  probability  of  receiving  yl  If  a  1  is  transmitted,  what  is  the  probability 
of  receiving  yl  If  the  decoder  knows  that  the  channel  is  an  AWGN  channel,  and  knows  the  Es/Nq  of  the 
channel,  it  can  compute  the  correct  probabilities.  If  the  decoder  uses  a  channel  model  that  differs  from  the 
true  channel,  it  will  compute  different  probabilities,  which  could  degrade  its  performance.  In  our  simula¬ 
tions,  the  decoder  always  used  a  channel  model  that  exactly  matched  the  channel. 


4.5  SUMMARY  OF  PARAMETERS  VARIED 

We  varied  seven  different  parameters: 

1.  The  Es/Nq  of  the  AWGN  channel  ranged  from  -5.5  to  3.8  dB. 

2.  The  block  size  N  ranged  from  512  to  65536. 

3.  The  code  rate  r  =  Ki/N  ranged  from  0.25  to  0.9. 

4.  The  Es/Nq  that  the  code  was  designed  for  ranged  from  3  dB  below  to  3  dB  above  the  Es/Nq 
of  the  channel. 

5.  The  CRC  length  d  ranged  from  4  to  24. 

6.  The  CRC  polynomial:  we  used  four  different  polynomials  with  d-  16,  and  one  polynomial  for 
each  other  length  tested.  All  of  these  polynomials  were  taken  from  [8]  or  [9]. 

7.  The  list  size  L  ranged  from  1  to  64.  Note  that  the  list  size  can  be  any  positive  integer,  but  all 
the  list  sizes  we  have  seen  in  the  literature  were  powers  of  two.  We  also  have  tested  only  pow¬ 
ers  of  2. 

We  specify  an  FEC  system  by  choosing  values  for  parameters  2  through  7,  and  we  test  the  system  by  com¬ 
puting  the  BER  as  a  function  of  E^ /No. 

Coding  theorists  typically  compare  FEC  systems  by  specifying  a  target  BER  or  FER,  and  finding  the 
Ei) /No  at  which  each  system  achieves  the  target.  The  difference  between  two  such  E^/Nq's  is  called  cod¬ 
ing  gain.  For  most  of  our  tests,  we  used  the  target  BER  =  10-5,  because  this  is  the  target  BER  specified  in 
some  Department  of  Defense  specifications,  such  as  in  Table  XVI  of  [10].  An  expert  at  SSC  Pacific  told  us 
that  for  TCP/IP  transmissions,  the  target  BER  is  10-8.  However,  it  takes  a  large  number  of  trials  to  mea¬ 
sure  a  BER  this  low,  and  we  could  only  do  this  for  a  few  cases. 

In  practice,  N,  r,  and  L  must  be  chosen  for  the  requirements  of  a  particular  system  because  they  have 
a  large  effect  on  throughput,  delay,  and  complexity.  In  contrast,  the  CRC  length,  CRC  polynomial,  and 
code  design  Es/ No  have  little  effect  on  throughput,  delay,  and  complexity.  Therefore,  for  any  given  com¬ 
bination  of  N ,  r,  L,  and  target  BER,  there  is  a  best  combination  of  CRC  length,  CRC  polynomial,  and 
code  design  Es/Nq\  the  combination  that  achieves  the  target  BER  at  the  lowest  E^/Nq. 
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5.  RESULTS 


The  starting  point  for  our  investigation  of  CRC-aided  list  decoding  was  the  example  shown  at  the  be¬ 
ginning  of  [5]:  N  =  2048,  code  rate  =  1/2,  code  design  Es/Nq  =  -1.01  dB,  CRC  length  =  16,  and  list  size 
=  32.  The  authors  of  [5]  did  not  specify  what  CRC  polynomial  they  used.  We  started  with  the  polynomial 
x16  +  x15  +  x2  +  1,  called  “CRC-16-IBM”  in  [8]. 

Preliminary  tests  suggested  that  code  design  Es/Nq  could  be  varied  over  a  wide  range  without  much 
effect  on  BER  performance.  As  a  result,  we  were  not  always  careful  in  choosing  the  code  design  Es/Nq.  6 


5.1  EFFECT  OF  VARYING  LIST  SIZE 

Figure  3  shows  the  effect  of  changing  the  list  size.  All  of  these  tests  were  performed  using  N  =  2048, 
code  rate  =  1/2,  code  design  Es/Nq  =  -1.01  dB,  and  the  CRC  polynomial  x 16  +  x 15  +  x2  +  1,  except  that 
the  test  with  L-  1  used  no  CRC.  (With  L-  1,  a  CRC  cannot  help  correct  errors.) 


BER 


E  1,/No  (dB) 

Figure  3.  BER  vs.  Eb/N0  for  N  =  2048,  rate  =  1/2,  and  varying  list  sizes. 


LIST 

SIZE 

-*-16 

-^64 


6The  results  in  this  section  are  not  listed  in  the  order  they  were  obtained.  For  some  of  these  tests,  the  choice  of  code  design 
Es /N0  was  influenced  by  the  results  shown  in  Section  5.6. 
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The  figure  shows  significant  improvement  as  list  size  is  increased  from  1  to  4,  and  rapidly  diminishing 
improvements  as  list  size  is  increased  further.  We  chose  to  use  L  —  4  for  most  of  our  subsequent  experi¬ 
ments. 


5.2  EFFECT  OF  VARYING  BLOCK  SIZE 


Figure  4  shows  the  effect  of  changing  the  block  size.  All  of  these  tests  were  performed  using  L  =  4, 
code  rate  =  1/2,  code  design  E8/Nq  =  -1.01  dB,  and  the  CRC  polynomial  x 16  +  x 15  +  x1  +  1. 


BLOCK 
SIZE 
—  1024 

—2048 

♦—4096 

■-8192 

k- 16384 

•-32768 

■1—65536 


Again  we  see  diminishing  improvement  with  each  doubling  of  the  block  size. 


5.3  EFFECT  OF  VARYING  CODE  RATE 

For  this  set  of  tests,  we  selected  various  combinations  of  block  size  and  code  rate,  and  determined  the 
Eb/No  at  which  the  BER  is  10-5.  All  of  these  tests  were  done  with  L  =  4  and  the  CRC  polynomial  x16  + 
x15+x2  +  l.  The  code  design  Es/Nq  was  chosen  to  be  close  to  the  Es/Nq  at  which  we  expected  to  achieve 
BER  =  1CT5. 

The  previous  figures  showed  BER  over  a  range  of  E^/Nq  values,  but  Figure  5  shows  only  the  E^/Nq 
needed  to  achieve  BER  =  10-5.  Although  E^/Nq  is  still  on  the  horizontal  axis,  it  is  now  the  dependent 
variable,  with  code  rate  as  the  independent  variable.  The  same  curve  tells  us,  for  a  given  E^ /No,  what  is 
the  highest  code  rate  we  can  use  while  keeping  the  BER  below  10-5. 
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1 


CODE 

RATE 


Eb/N0  (dB) 


Figure  5.  Eb/N0  needed  to  achieve  BER  =  10-5  for  various  block  sizes  and  code  rates. 


As  suggested  by  an  expert  at  SSC  Pacific,  we  compared  the  results  to  the  performance  of  the  FEC  code 
used  in  the  DVB-S2  standard.  In  Figure  5,  the  DVB-S2  points  are  not  connected  because  these  points  cor¬ 
respond  to  all  1 1  code  rates  in  the  standard.  In  contrast,  the  code  rate  of  the  polar  codes  can  be  adjusted  in 
increments  of  1/N. 

Ideally,  we  should  see  a  smooth  curve  for  each  polar  block  size.  We  believe  the  jaggedness  is  mostly 
caused  by  inconsistency  in  how  the  code  design  Es/Nqs  were  chosen. 

We  did  not  compute  error  bars  for  this  graph.  For  each  polar  code  data  point,  we  estimated  the  re¬ 
quired  Eb/No  by  interpolating  the  BER  between  two  E^/Nq  values  that  we  tested.  The  interpolation  was 
linear  when  viewed  on  a  log-log  scale.  This  produces  some  error  because  the  BER  curve  is  not  perfectly 
linear,  and  the  points  we  interpolated  between  were  affected  by  sampling  error.  To  limit  the  error,  we  sim¬ 
ulated  at  least  105  blocks  for  each  point,  and  the  E^/Nq's  we  interpolated  between  were  at  most  0.25  dB 
apart. 

BER  performance  of  the  DVB-S2  FEC  is  hard  to  find,  because  within  the  standard  the  relevant  metric 
is  packet  error  rate  (PER),  not  BER.  We  estimated  the  DVB-S2  points  using  Figures  4  and  22  of  [1 1].  We 
assumed  that  a  BER  of  10-5  corresponds  approximately  to  a  PER  of  10-3.  This  should  not  make  much 
difference  because  the  PER  curves  shown  in  Figure  4  of  [1 1]  are  very  steep.  We  believe  these  points  are 
correct  within  0.05  dB. 

Figure  6  shows  the  same  data  as  Figure  5,  but  with  Es/Nq  on  the  horizontal  axis  instead  of  Eb/No. 
This  is  useful  because,  from  a  code  design  perspective,  the  Es/Nq  is  given,7  but  the  E^/Nq  can  be  changed 
by  changing  r.  Recall  these  are  related  by  Eb/No  =  ( Es/No)/r . 

7In  a  broader  RF  design  perspective,  the  Es/N0  can  be  changed  in  several  ways,  such  as  changing  the  transmit  power  or  the 
symbol  duration. 
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1 


Es/N0  (d  B) 

Figure  6.  Ea/N0  needed  to  achieve  BER  =  10-5  for  various  block  sizes  and  code  rates 


The  DVB-S2  results  form  a  stairstep  curve  due  to  the  limited  choice  of  code  rates.  For  example,  sup¬ 
pose  the  Es/Nq  is  -2.1  dB  and  we  are  required  to  maintain  BER  <  10-5.  Using  DVB-S2,  we  can  achieve 
a  code  rate  of  0.5.  Now  suppose  the  Es/Nq  increases  to  -1.3  dB.  This  is  not  high  enough  to  use  a  higher- 
rate  DVB-S2  code,  so  a  DVB-S2  user  would  continue  to  use  rate  0.5.  In  contrast,  using  a  polar  code  of 
approximately  the  same  length,  at  -1.3  dB  we  could  use  rate  0.54.  In  the  range  -2  dB  <  Es/Nq  <  -0.9  dB, 
polar  codes  of  length  65536  can  provide  up  to  15%  more  throughput  than  DVB-S2  codes. 


5.4  EFFECT  OF  VARYING  CRC  POLYNOMIAL 

We  compared  four  different  polynomials  of  length  16: 

1.  The  previously  mentioned  CRC-16-IBM. 

2.  x16  +  x14  +  x13  +  x12  +  x10  +  xs  +  x6  +  x4  +  x3  +  x1  +  1,  from  Table  3  of  [9].  We  refer  to  this 
polynomial  as  “Koopman”. 

3.  x16  +  x12  +  x5  +  1,  called  “CRC-16-CCITT”  in  [8]. 

4.  x16  +  x15  +  x14  +  x11  +  x6  +  x5  +  x2  +  x1  +  1,  called  6tCRC-16-CDMA2000”  in  [8]. 

Figure  7  shows  the  results  of  using  these  four  polynomials  with  N  =  2048,  r  —  1/2,  list  size  4,  and  design 
Es/Nq  -1.01  dB.  Figure  8  shows  the  results  of  using  these  four  polynomials  with  N  =  2048,  r  =  1/2,  list 
size  32,  and  design  Es/Nq  -1.25  dB.  In  both  cases,  the  design  Es/Nq  was  chosen  to  be  approximately  the 
Es/Nq  at  which  the  BER  is  10-5. 
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BER 


IBM  KQOPMAN  CCITT  CDMA20Q0 


IE-6 


■  Eb/NO  2.1  ■  Eb/fM 0  2.2 

Figure  7.  Comparison  of  16-bit  CRCs  with  list  size  4. 


IBM  KOOPMAN  CCITT  CDMA20Q0 

■  Eb/NO  1.65  ■  Eb/NO  1.75 

Figure  8.  Comparison  of  16-bit  CRCs  with  list  size  32. 

The  effect  of  changing  the  polynomial  is  smaller  than  the  measurement  error,  and  too  small  to  matter. 
For  each  of  the  eight  systems  tested,  we  interpolated  to  find  the  E^/Nq  at  which  the  BER  is  10-5.  For  both 
L  —  4  and  L  =  32,  CRC-16-IBM  was  best,  but  the  difference  between  best  and  worst  was  0.005  dB  and 
0.013  dB,  respectively.  We  decided  it  was  not  necessary  to  do  further  comparisons  of  polynomials  with  the 
same  length. 


IE-4 


BER 

IE-5 


5.5  EFFECT  OF  VARYING  CRC  LENGTH 

We  tested  CRC-aided  list  decoding  using  the  CRC  lengths  and  polynomials  shown  in  Table  1 . 

As  mentioned  in  Section  4.5,  the  best  CRC  length  may  depend  on  N,  the  code  rate,  the  list  size,  and 
the  target  BER.  We  ran  tests  to  determine  the  best  length  in  a  few  different  cases. 
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Table  1 .  CRC  polynomials  tested. 


CRC  length 

Polynomial 

Source 

4 

x4  +  x  +  1 

CRC-4-ITU  from  [8] 

6 

X6  +  X  +  1 

CRC-6-ITU  from  [8] 

8 

x6  +  x7  +  x6  +  x4  +  x2  +  1 

CRC-8  from  [8] 

10 

xlu  +  x9  +  x5  +  x4  +  X  +  1 

CRC- 10  from  [8] 

12 

x12  +  x11  +  x3  +  x2  +  X  +  1 

CRC- 12  from  [8] 

14 

x14  +  x9  +  x8  +  x7  +  x6  +  x4  +  1 

from  Table  3  of  [9] 

16 

x16  +  x15  +  x2  +  1 

CRC-16-IBM  from  [8] 

24 

x24  +  x22  +  x2U  +  x19  +  x18  +  x16  +  X14  +  x13 
+X11  +  x10  +  x8  +  x7  +  X6  +  X3  +  X  +  1 

CRC-24  from  [8] 

5.5.1  Preliminary  Test 


In  this  test  we  compared  CRC  lengths  d-  8,  12,  16,  and  24.  For  all  four  lengths,  we  used  L-4  and 
the  same  polar  code,  with  N  =  2048  and  K  =  1040,  designed  for  Es/Nq  -1.01  dB.  We  tested  them  at 
Eb/No  2.1  and  2.2  dB.  The  results  are  shown  in  Figure  9. 


Figure  9.  Comparison  of  CRC  lengths  with  N  =  2048,  K  =  1040,  and  list  size  4. 


We  can  see  that  length  8  is  better  than  the  others.  This  result  may  be  confusing.  In  all  four  cases,  the 
frozen  bits  were  the  same,  providing  the  same  error  correction,  and  the  longer  CRCs  are  better  at  filtering 
out  incorrect  answers  on  the  list,  so  how  can  the  shorter  CRC  win?  The  reason  is  that  we  tested  them  at 
the  same  E^/Nq,  not  at  the  same  Es/Nq.  The  code  rate  was  r  =  1(^o^,  so  a  larger  d  meant  a  smaller  r 
and  lower  Es/Nq,  i.e.,  more  noise.  The  effect  of  the  longer  CRC  was  not  enough  to  compensate  for  more 
noise. 

This  was  not  exactly  a  fair  test.  In  this  test,  the  8-bit  CRC  was  used  with  rate  1032/2048,  and  the 
longer  CRCs  were  used  with  lower  rates.  As  shown  in  Section  5.3,  using  a  lower  code  rate  normally  pro¬ 
duces  a  coding  gain.  Therefore,  if  we  repeated  the  test  with  all  four  lengths  at  rate  1032/2048,  the  longer 
lengths  would  have  performed  even  worse. 
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In  subsequent  tests,  we  always  compared  codes  with  the  same  length  and  rate. 


5.5.2  Baseline  Test 

Since  the  lengths  d  >  12  performed  poorly  in  the  preliminary  test,  in  the  baseline  test  we  compared 
CRC  lengths  4,  6,  8,  and  10.  In  all  four  cases,  we  used  N  =  2048,  r  =  1/2,  design  Es/N$  =  -0.91  dB,  and 
list  size  4.  We  tested  them  at  E^/Nq  2.05,  2.15,  and  2.25  dB.  The  results  are  shown  in  Figure  10. 


4  6  8  10 


IE-6 

■  Eb/NO  2.05  ■  Eb/N0  2.15  ■  Eb/N0  2.25 

Figure  10.  Comparison  of  CRC  lengths  with  N  =  2048,  r  =  1/2,  and  list  size  4. 

The  8-bit  CRC  appears  to  be  best  of  the  four,  with  the  lowest  BER  at  both  2.05  and  2.15  dB.  The  6-bit 
CRC  performed  slightly  better  at  2.25  dB,  but  the  difference  is  well  within  measurement  error. 
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5.5.3  Test  With  a  Different  List  Size 


For  this  test,  we  used  list  size  32,  N  =  2048,  r  —  1/2,  and  design  Es/Nq  =  -1.36  dB.  With  a  larger 
size,  there  is  a  higher  probability  that  the  list  will  include  an  incorrect  codeword  that  passes  the  CRC.  Intu¬ 
itively,  it  makes  sense  to  mitigate  this  by  using  a  longer  CRC.  That  is  why  we  chose  to  test  a  longer  CRC 
in  this  test  than  in  the  baseline  test.  We  compared  CRC  lengths  4,  8,  10,  and  12.  We  tested  them  at  E^/Nq 
1.7,  1.8,  and  1.9  dB.  The  results  are  shown  in  Figure  11. 


4  8  10  12 


■  Eb/INO  1.7  ■  Eb/NO  1.8  ■Eb/ND1.9 


Figure  1 1 .  Comparison  of  CRC  lengths  with  N  =  2048,  r  =  1/2,  and  list  size  32. 

The  10-bit  CRC  appears  to  be  best  of  the  four,  with  the  lowest  BER  at  both  1.8  and  1.9  dB.  The  8-bit 
CRC  performed  slightly  better  at  1.7  dB,  but  the  difference  is  well  within  measurement  error. 

5.5.4  Test  With  a  Different  Code  Rate 

For  this  test,  we  used  r  =  0.7,  N  =  2048,  list  size  4,  and  design  Es/Nq  =  0.9  dB.  We  compared  CRC 
lengths  6,  8,  and  10.  We  tested  them  at  E^/Nq  2.9,  3.0,  and  3.1  dB.  The  results  are  shown  in  Figure  12. 

The  8-bit  CRC  appears  to  be  best,  with  the  lowest  BER  at  both  3.0  and  3.1  dB.  The  6-bit  CRC  per¬ 
formed  slightly  better  at  2.9  dB,  but  the  difference  is  well  within  measurement  error. 
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■  Eb/lN 0  2.9  BEb/IN0  3.0  B  Eb/NO  3.1 

Figure  12.  Comparison  of  CRC  lengths  with  N  =  2048,  r  =  0.7,  and  list  size  4. 


5.5.5  Test  With  a  Different  Block  Size 


For  this  test,  we  used  N  =  32768,  r  —  1/2,  list  size  8,  and  design  E8/Nq  =  -2.25  dB.  We  compared 
CRC  lengths  6,  8,  and  10.  We  tested  them  at  E^/Nq  1.05  and  1.15  dB.  The  results  are  shown  in  Figure  13. 


IE-4 
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6  8  10 


■  Eb/NO  1.05  ■  Eb/NO  1. 15 


Figure  13.  Comparison  of  CRC  lengths  with  N  =  32768,  r  =  1/2,  and  list  size  8. 


The  8-bit  CRC  appears  to  be  best,  with  the  lowest  BER  at  both  1.05  and  1.15  dB. 
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5.5.6  Test  With  a  Different  Target  BER 


For  this  test,  we  used  N  =  2048,  r  —  1/2,  design  Es/Nq  =  -0.91  dB,  and  list  size  4,  which  are  the 
same  parameters  used  in  the  baseline  test.  We  tested  CRC  lengths  6,  8,  10,  and  12  at  E^/Nq  2.6  dB,  and 
lengths  6,  8,  10,  12,  14,  and  16  at  E^/Nq  2.7  dB.  The  results  are  shown  in  Figure  14. 


6  8  10  12  14  16 


IE-8 


■  Eb/NO  2.6  ■  Eb/NO  2.7 


Figure  14.  Comparison  of  CRC  lengths  with  N  =  2048,  r  =  1/2,  and  list  size  4. 


Recall  that  in  the  baseline  test,  length  8  was  best  for  a  target  BER  of  10-5.  It  appears  that  length  10  is 
best  for  a  target  BER  of  10-7,  and  length  14  is  best  for  a  target  BER  of  4  •  10-8.  It  appears  that,  in  general, 
a  lower  target  BER  means  a  larger  optimal  CRC  length.  One  previously  published  result  supports  this  hy¬ 
pothesis:  Figure  3  of  [12]  shows  a  comparison  between  CRC  lengths  8  and  32,  with  N  =  1024,  r  =  0.84, 
and  list  size  128  8,  with  E^/Nq  ranging  from  2  to  5  dB.  Both  achieve  BER  approximately  10-5  at  E^/Nq 
4  dB.  For  lower  E^/Nq  (equivalently,  for  higher  target  BER),  length  8  outperforms  length  32,  while  for 
El/ Nq  >  4  dB  (target  BER  <  10-5),  length  32  outperforms  length  8,  with  a  coding  gain  of  about  0.5  dB 
at  BER  =  10-7.  We  do  not  recall  seeing  any  other  published  results  comparing  two  different  CRC  lengths. 

5.5.7  CRC  Length  Summary 

For  a  list  size  of  4  and  a  target  BER  of  10-5,  use  an  8-bit  CRC.  The  ideal  CRC  length  increases  if  the 
list  size  is  increased  or  the  target  BER  is  decreased. 


5.6  EFFECT  OF  VARYING  CODE  DESIGN  Es/N0 

We  would  like  to  have  a  rule  that  when  the  channel  Es/ No  is  x  dB,  we  should  use  a  code  designed 
for  Es/ No  x  +  S  dB.  The  ideal  S  may  depend  on  N,  r,  L,  and  E3/Nq,  but  we  hope  to  find  a  S  that  will  be 
near-optimal  in  a  wide  range  of  cases. 

For  this  test,  we  used  N  =  2048,  r  =  1/2,  a  16-bit  CRC,  and  list  size  4.  The  5  values  we  tested  were 
-3,  -2,  -1,  -0.5,  0,  0.5,  1,  2,  and  3,  and  we  tested  all  of  these  at  E^/Nq  2.1  and  2.2  dB  (equivalently,  Es/No 

8No  polar  code  construction  method  is  specified  in  [12];  in  particular,  no  design  Es/N0  is  specified.  It  is  possible  that  the 
results  in  Figure  3  of  [12]  were  obtained  using  multiple  design  Es/Nq’s  to  match  the  Es/Nq’s  tested. 
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-0.91  and  -0.81  dB).  Thus,  we  tested  a  total  of  18  different  codes.  The  results  are  shown  in  Figure  15.  We 
obtained  the  best  results  with  5  =  —0.5. 

DESIGN  Es/NO  -  TESTED  Es/NG 

-3  -2  -1  -0.5  0  0.5  1  2  3 


BER 

IE -4 


IE -5 


■  Eb/NO  2.1  dB  ■  Eb/NO  2.2  dB 

Figure  15.  Comparison  of  design  Es/N0's  with  N  =  2048,  r  =  1/2,  16  bit  CRC,  and  list  size  4. 

We  have  not  had  time  to  repeat  this  test  with  different  parameters,  but  we  did  use  this  result  with  N  = 
65536  and  several  different  code  rates,  to  improve  the  results  shown  in  Figure  5.  Several  points  on  the  N  = 
65536  curve  appeared  to  be  too  far  to  the  right  relative  to  the  others.  We  recomputed  these  points  using  a  S 
near  -0.5,  and  these  points  moved  significantly  to  the  left.  As  a  result,  other  points  now  appear  to  be  too  far 
right. 
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6.  IMPLEMENTATION  DETAILS 

Our  decoder  software  is  written  in  C++.  It  is  based  on  the  pseudocode  in  [5],  which  is  designed  to  be 
used  with  a  systematic  polar  encoder.  Unlike  most  decoders  described  in  the  polar  coding  literature,  this 
decoder  does  not  use  the  logarithmic  domain  for  probabilities.  We  used  type  long  double  for  the  prob¬ 
abilities.9 

We  made  only  four  changes  to  the  pseudocode  from  [5].  First,  we  corrected  a  mistake  in  algorithm 
15:  lines  1  and  2  are  misplaced;  they  belong  after  “continue”.  The  same  correction  recently  appeared  in  a 
later  version  of  the  paper  [13].  Second,  we  found  that  Algorithm  12  did  not  work  as  written.  The  indices 
in  pathlndexToArray Index  are  used  both  in  arrayPointer_P,  to  point  to  float  arrays,  and  in 
arrayPointer_C,  to  point  to  bit  arrays.  We  found  that  when  a  float  array  is  copied,  the  corresponding 
bit  array  must  also  be  copied,  and  vice  versa,  so  that  the  indexing  remains  consistent. 

The  third  change  is  necessary  because  the  pseudocode  in  [5]  is  for  a  non-CRC-aided  decoder.  The 
CRC-checking  part  of  the  algorithm  is  described  in  the  text,  but  no  pseudocode  is  provided.  We  modified 
the  f  indMost  Probable  Path  algorithm  to  implement  CRC-checking. 

Before  calling  f  indMostProbablePath,  the  decoder  computes  L  candidate  codewords  xq  through 
xl- i  and  a  probability  pi  for  each  one.  The  function  f  indMostProbablePath  keeps  track  of  four 
variables: 

•  pPrime,  the  highest  probability  found  so  far 

•  IP  rime,  the  index  where  pPrime  was  found 

•  pPrimeCrc,  the  highest  probability  found  so  far  among  codewords  that  pass  CRC 

•  IPrimeCrc,  the  index  where  pPrimeCrc  was  found 

IPrimeCrc  is  initialized  to  -1,  which  is  invalid,  and  the  other  three  are  initialized  to  0. 

f  indMostProbablePath  has  a  loop  where  the  index  l  ranges  from  0  to  L  —  1.  If  pi  >  pPrime, 
the  function  updates  pPrime  and  IP  rime.  Then  if  p\  >  pPrimeCrc,  the  function  checks  to  see  if  x/ 
passes  CRC.  If  it  passes,  the  function  updates  pPrimeCrc  and  IPrimeCrc.  At  the  end  of  the  loop,  it 
computes  the  flag  passedCrc  =  (IPrimeCrc  >  —1).  If  the  flag  is  true,  it  returns  IPrimeCrc  as  the  most 
probable  path  index,  otherwise  it  returns  IPrime.  Note  that  it  is  usually  not  necessary  to  check  CRC  for 
every  codeword  in  the  list.  passedCrc  is  also  returned  via  pointer. 

Checking  the  CRC  is  a  three-step  process,  f  indMostProbablePath  must  first  call  a  bit-reversal 
function  to  compute  w /  =  II yx/,  then  copy  some  of  the  entries  to  form  (w i)A,  before  it  can  compute  the 
CRC. 

The  final  change  we  made  is  that  in  [5],  the  decoder  outputs  the  entire  TV-bit  codeword  x,  but  our  de¬ 
coder  outputs  its  estimate  of  the  K- bit  input  to  the  polar  encoder.  This  output  is  via  pointer,  and  the  return 
value  is  passedCrc. 

To  test  the  decoder,  we  repeatedly  generate  FQ  random  bits,  encode  them,  simulate  transmission  through 
an  AWGN  channel,  decode  the  channel  output,  and  compare  the  random  bits  to  the  first  K{  bits  output  by 
the  decoder.  We  did  not  count  errors  in  the  CRC  bits. 

9 We  used  two  different  compilers.  This  type  was  16  bytes  in  one  compiler  and  12  bytes  in  the  other. 
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6.1  DECODING  SPEED 


Reference  [13]  shows  that  the  list  decoder  requires  0(LN  log  N)  operations.  With  N  =  65536,  r  = 

1/2,  and  L  =  4,  our  decoder  runs  in  0.3  seconds  on  one  core  of  an  Intel®  Xeon®  X7560  processor.  This 
speed  enables  throughput  of  up  to  100  kbps. 

Our  decoder  is  designed  to  be  as  simple  as  possible.  Other  CRC-aided  list  decoder  designs  have  been 
proposed  to  run  much  faster,  both  in  software  and  hardware.  Almost  all  such  results  concern  block  sizes 
512,  1024,  or  2048.  For  example,  [12]  showed  that  a  list  decoder  with  N  =  2048,  r  =  0.84,  and  L  =  32 
could  run  in  433  ms,  with  throughput  33  Mbps.  We  have  not  seen  any  results  that  combined  high  speed 
with  the  error-correction  performance  that  we  achieved  with  N  =  65536.  The  closest  is  [14],  which  de¬ 
scribes  a  decoder  with  N  =  32768,  r  =  0.9,  and  L  =  32,  but  the  speed  of  this  decoder  is  not  given.  It  achieves 
BER  10-5  at  Eb /No  4.2  dB,  which  is  0.3  dB  worse  than  what  we  achieved  at  the  same  code  rate  with  N  = 
65536  and  L  =  4.  We  have  not  seen  any  other  examples  of  CRC-aided  list  decoding  with  N  >  2048  in  the 
existing  literature. 

If  we  assume  that  the  decoder  of  [12]  can  be  scaled  up  to  N  =  65536  with  runtime  proportional  to 
0(N  log  N),  it  would  run  in  0.02  seconds,  with  throughput  up  to  23  Mbps,  and  would  probably  provide 
a  small  coding  gain  over  our  decoder. 
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7.  CONCLUSION 


In  any  application  for  which  the  DVB-S2  FEC  is  considered,  polar  coding  with  CRC-aided  list  de¬ 
coding  with  N  =  65536  should  also  be  considered.  With  L-  4  in  an  AWGN  channel  it  approximates  the 
DVB-S2  results  when  compared  at  the  same  data  rate,  and  can  provide  up  to  15%  higher  throughput  by  us¬ 
ing  code  rates  not  provided  in  the  DVB-S2  standard.  The  current  runtime  of  0.3  s  may  be  fast  enough  for 
some  applications  up  to  100  kbps.  Higher  speed  can  be  achieved  using  techniques  in  the  existing  literature. 
Further  work  is  needed  to  accomplish  the  following: 

•  Incorporate  these  techniques  into  our  software 

•  Test  both  polar  coding  and  DVB-S2  coding  with  BER  target  10-8 

•  Test  both  polar  coding  and  DVB-S2  coding  in  more  complex  channel  models  such  as  Nakagami  fad¬ 
ing 
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